Data Mart（materialized table）：

（我們會花相當多的時間來談論這件事）

• 定義：只處理簡單的 join，並按照商業單位（business unit）或知識領域（knowledge of domain）區分不同的 mart。
• 機制：在這個階段，是我們的 data pipeline 中的最後一個階段，通常也會在這個時候將表格實體化存起來（換句話說，前面的 view 只有在每日/每週/每月排程的時候觸發，平常只需要存 code 即可。）開始花存資料的容量費用。而每一個 mart，則具備特定的意義和目的。
  • 工程機制：由於當代的 lakehouse 技術中，儲存成本非常低，而運算成本相對高。所以，當我們可以把 de-norm 後的表格（有些人習慣直接稱呼為「大表」）存起來，避免業務單位需要進行大量的 joining，會非常有幫助。這樣的處理方式，會與傳統的 star schema 非常不同（雪花架構、星型架構）。
  • 商業機制： 為了達成上述的商業目的，dbt 期待 data mart 的區分方式，是以商業實體作為這個階層的 record 概念。例如，每一個訂單、每一個地區、每一個 click、每一個 event、或是每一筆繳稅費用，各自獨立成為一行 record。

看一個阿華炒麵店的例子

models/marts
├── rental
│   ├── _rental__models.yml
│   ├── rental_fees.sql
│   └── water_and_electricity_fees.sql
└── tax
    ├── _tax__models.yml
    ├── business_taxes.sql
    └── land_taxes.sql

在這個例子中，哪怕一樣是「支出」行為（rental，租金相關；tax，稅務相關），但因為不屬於相同的商業實體，所以一樣區分成不同的 mart。

讓我們來做個思考練習：當你今天是業務單位的 DA/BA 的時候，你會希望哪些大表被 join 好在一起，哪些可以分開來，以讓你的 query 費用最小化呢？

如果我把所有的資料放在一起，是不是稅務部門要查資料的時候，每次都要選 payments.sql，然後 where paymen_type = "tax"？換句話說，越理解商務部門的決策習慣，analytic engineers 越是有辦法精簡 data mart 的架構設計。